1. Field of the Invention
The invention relates to the field of network systems. More specifically, the invention relates to the generation of an alert configuration file.
2. Background of the Invention
The TelAlert program available from Telamon of Oakland, Calif. provide individuals the capability to transmit messages to remote destinations over various telecommunication delivery mechanisms. In one prior art technique, TelAlert is used by business enterprises to transmit alert messages to a multitude of remote destinations. Here, TelAlert transmits alert messages generated by monitoring management, help desk, and/or dispatch applications to the responsible enterprise support staff. For example, a network help desk may use TelAlert to dispatch an alert message to the pager of a network technician, indicating perhaps, that a specific router is inaccessible on the network. TelAlert may transmit alert messages by way of a number of telecommunication delivery mechanisms including pagers, telephones, email, loudspeakers, signboards, among other examples.
Configuration Methods
FIG. 1A illustrates a block diagram of a manner in which a TelAlert system is configured in the prior art. The TelAlert system is configured by way of two configuration methods. The first configuration method is where a TelAlert configuration file 115 (called a TelAlert.ini 115 file) is edited directly, using a text editor. The other configuration method uses the TelAdmin application 190, also available from Telamon of Oakland, Calif.
The telalert.ini 115 file stores configuration information defined by sections, definitions, and keywords, as will be further described below. Traditionally, the TelAlert system is configured by opening the telalert.ini 115 file in a text editor, typing the necessary configuration changes in the appropriate locations (e.g., sections), and then saving the telalert.ini file. The telalert.ini 115 file is then compiled into the telalert.sect 120 file to be used by the Telalert system to transmit alert messages, as will be further described below.
When editing the telalert.ini 115 file, configuration information may be entered and modified in more or less any order, since doing so is simply a matter of typing and initializing. However, one problem with editing the telalert.ini 115 file is that there is no way to perform validation checks to ensure the configuration information is valid. Errors in modification of keywords and relationships will not be discovered until the compilation of the telalert.sects 120 file is performed, thereby, compromising the integrity of the TelAlert system. For example, editing the telalert.ini 115 file does not allow for referential integrity checks (e.g., must define X before referencing to X), value validation checks (e.g., protect against placing a character type in a number type field), typographical error checking, nor provide enforcement of general TelAlert system limitations (e.g., enforce maximum message size to be less than or equal to 1920 characters, among other examples). Therefore, in some cases, inconsistency in the configuration information may not be discovered until after an alert message fails to alert the necessary support staff and thereby delaying its resolution.
In contrast, the TelAdmin application 190 allows an alternative configuration method to provide configuration information to the TelAlert system. Here, the TelAdmin application 190 is used to perform configuration modifications to the telalert.sects 120 file directly. The TelAdmin application 190 is a Microsoft Windows-based graphical configuration tool. Although the TelAdmin application 190 runs only on a Microsoft Windows NT platform, it may be used to configure TelAlert installations running on UNIX operating system based platforms.
The TelAdmin application 190 is not a simple graphical configuration-file editor, but rather a front end for a multiuser transactional database system. In this way, the TelAdmin application 190 is similar in design to a Microsoft Windows' Registry Editor that is well known in the art. FIG. 2 illustrates a view of the TelAdmin application user interface in the prior art. In FIG. 2, the TelAdmin application 190 displays a graphical representation of TelAlert's sections (for example, the Configuration and Destination sections) in a tree structure in the left pane of the main window 210. The definitions under each section (if any) are displayed in the right pane 220 when one clicks a section icon on the tree (much as the Microsoft Windows Registry Editor displays registry keys and values).
Depending on the type of keyword value, the end-user may provide a value by a pull-down list, type a string or number in a field, or set a time, date, or some other type of formatted data using spinners. The TelAdmin application relies on pull-down menus having options that are sometimes dynamically generated, based on the current state of the telalert.sects 120 file. When configuring a keyword that refers to another keyword (for example, a Port definition from a Configuration definition, or a Configuration definition from a Destination definition), the keyword referred to must already exist; otherwise, it will not appear among the options presented in the pull-down menu. However, again, the TelAdmin application has no way to ensure the existence of this configuration information prior to dynamically generating the pull-down menus.
When the TelAlert Administrator finishes making configuration changes, the administrator may click the ‘Save’ button to commit the changes, click ‘Undo’ button to undo any changes made, or click ‘Cancel’ button to dismiss the dialog without saving changes. However, upon saving the changes, the telalert.sects 120 file is instantly overridden and therefore no backup file is saved from which to back-out any erroneous configuration changes made.
In addition, each time the telalert.sects 120 file is edited or compiled, the transmission of alert messages are halted until the TelAlert system and telecommunication delivery mechanisms are reinitialized with the updated configuration information. Depending on the number of telecommunication delivery mechanisms, the reinitialization may take a substantial amount of time, thereby, again, delaying the delivery of an alert message to the necessary support staff. The problem may also be compounded, depending on the number of end-users updating the telalert.sects 120 file, causing a reinitialization each time the telalert.sects 120 file is updated. Thereby causing a substantial delay to the delivery and resolution of alert messages.
Furthermore, the TelAdmin application 190 may manage multiple TelAlert servers at once in a single instance of the TelAdmin application. By using the TelAdmin application 190, multiple end-users may simultaneously reconfigure the TelAlert system, and a record-locking system ensures that they do not accidentally overwrite each other's changes, by defining an Owner section and an Owner keyword within the TelAlert configuration file. However, the TelAdmin application 190 is limited to this level of granularity in its access control. Therefore, for example, department heads may use the TelAdmin application to define access rights that control which system administrators may configure which TelAlert sections and definitions.
In addition, when operating in an environment that manages multiple TelAlert systems, the TelAdmin application 190 is limited to “pushing” configuration information to the remote servers. Hence, only one remote server may be updated at any one time. This increases the amount of time to configure multiple systems.
While it is technically possible to switch from one configuration method to the other (that is, from using the TelAdmin application to editing telalert.ini 115 file, and vice-versa), care must be taken not to overwrite any of changes accidentally.